Skip to content

WASM (WebAssembly)#107

Open
SamuelMarks wants to merge 3 commits into
Zaneham:masterfrom
SamuelMarks:wasm
Open

WASM (WebAssembly)#107
SamuelMarks wants to merge 3 commits into
Zaneham:masterfrom
SamuelMarks:wasm

Conversation

@SamuelMarks

Copy link
Copy Markdown

WiP, but it works:
Screenshot 2026-06-10 at 2 21 06 PM

Hosted up here also: https://samuelmarks.github.io/barracuda-web/

@Zaneham

Zaneham commented Jun 15, 2026

Copy link
Copy Markdown
Owner

Kia ora @SamuelMarks, and good on ya for this. A live in-browser playground is something I'd half-dreamed about for BarraCUDA and never expected anyone to just go and build. It's basically Godbolt for the compiler, and watching a from-scratch toolchain run a .cu straight in the browser is genuinely a bit magic. The hosted demo made me grin like an idiot. Choice effort, seriously.

A few notes, none of them blockers, and all good knowing it's WiP:

Committed artifacts. web/barracuda.wasm and the minified web/barracuda.js are sitting in the tree. Could we gitignore those and generate them via make wasm (or a small CI job)? For a compiler repo I'd rather not carry a binary blob that goes stale the moment anyone touches a .c, and you've already got the demo hosted, so master doesn't need to ship the build output. Happy to wire up a gh-pages or release-artifact step if that'd help.

build_wasm.sh portability. The export PATH="/opt/homebrew/bin:$PATH" line only helps on a Mac. Reckon we can drop it and just lean on emsdk being on PATH, so she runs sweet on Linux/CI too.

Source list. find src -name "*.c" will drift from the Makefile's curated object list over time (grabs anything new under src/, misses top-level runtime/). Driving the WASM build off the same list the Makefile uses would keep the two honest.

Test deps. puppeteer pulls a whole Chromium down, which is a chunky dependency for this repo. The node FS sanity test (test_wasm_run.js) is lovely and light, though. Could we lean on that one for CI and keep the puppeteer e2e as an opt-in manual target?

Tiny one: in the main.c -o change, on fopen failure it falls back to stdout. I'd lean towards erroring there rather than dumping asm to stdout, but it's a nitpick.

The worker's nicely done too by the way, capturing stdout/stderr, the MEMFS round-trip, the exit-code checks. Mean foundation to build on. Cheers, thanks for putting the work in, legend!

* Consolidate WASM build into Makefile
  The standalone build_wasm.sh script has been removed, and its logic is now natively supported via the make wasm target. This updates test_wasm_build.sh to use the new Makefile target and introduces make wasm_test_e2e for running web UI tests.

* Stop tracking WASM artifacts in version control
  web/barracuda.js and web/barracuda.wasm are build outputs and should not be committed to the repository. They have been deleted from the tree and added to .gitignore.

* Fail fast on AMDGPU backend file I/O errors
  Fixed an issue in src/main.c where failing to open the requested output file would print an error but then silently fall back to emitting assembly to stdout. It now properly aborts with BC_ERR_IO.

* Clean up unused package.json
  Removed package.json since puppeteer is now handled via an ad-hoc local installation check in the Makefile.
@SamuelMarks

Copy link
Copy Markdown
Author

Kia ora! - Happy to help.

  1. Committed Artifacts: I've removed web/barracuda.wasm and web/barracuda.js from the repository and added them to .gitignore. They are now treated as generated artifacts and will not be tracked.
  2. build_wasm.sh Portability: I deleted the standalone build_wasm.sh script and consolidated the WASM build logic directly into the Makefile under the wasm target. This resolves the hardcoded Mac-specific paths and keeps the build source list in sync.
  3. Test Dependencies: I've removed the package.json with the Puppeteer dependency. The end-to-end tests are now relegated to an opt-in manual target (make wasm_test_e2e) that checks for a local ad-hoc installation of Puppeteer before proceeding.
  4. File I/O Error Handling: I fixed the logic in src/main.c. The compiler now fails fast and aborts with a BC_ERR_IO error if it cannot open the requested -o output file, rather than silently dumping assembly to stdout.

Let me know if there is anything else that needs adjusting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants